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METHOD AND APPARATUS FOR REAL- deletion process at discrete points in time. Thus, during the 

TIME SECURE FILE DELETION period of time between successive executions, the storage 

device will contain insecurely deleted information, Further, 

CROSS REFERENCE TO RELATED conventional products can be prohibitively time consuming 

APPLICATIONS 5 because, to secure a storage device, they have to process the 

. . . . r tt * entire device to overwrite all unused storage space. 
The present application is a continuation of U.S. patent 

application Ser. No. 09/114,756 filed Jul. 13, 1998, now U.S. SUMMARY OF THE INVENTION 

Pat. No. 6,070,174 which is a continuation-in-part of U.S. , « ... . . . .. _ iU A , 

. . !■ *■ c xt r\Qtf\At\nAc ci jo in mm m accordance with the present invention, a method and 

patent application Ser. No. 08/940,746 filed Sep. 30, 1997, „ n ^ - , «i j i *• j-i a *u * 

. » -r. , T r^ vr r Ar,, n-,n 3° apparatus for real-time secure file deletion are disclosed that 

now identified as U.S. Pat. No. 5,991,778. j j • i j i j «i 

' provide advantages over previously developed secure file 

TECHNICAL FIELD OF THE INVENTION deletion methods and products. 

According to one aspect of the present invention, a 

The present invention relates in general to the field of method and apparatus provide enhancement of file system 

electronic systems, and more specifically to a method and 15 calls to a file system structure of an operating system. In 

apparatus for real-time secure file deletion. particular, the file system calls can be enhanced to provide 

real-time secure file deletion on an ongoing basis. According 

BACKGROUND OF THE INVENTION to the present mventioilj a filc system call mat is intended to 

File management processes executed by operating sys- perform a function with respect to data stored on a storage 

terns and system applications typically do not implement 20 device is intercepted. It is then determined whether the file 

secure file deletion. For example, in WINDOWS 95, dele- system call is of a type that should be processed. If not, the 

tion of a file does not make the contents of the file unre- original file system call is passed on through the file system, 

coverable. In fact, it can be a relatively simple process to If the file system call should be processed, supplemental 

recover the deleted file. Further, many common software processing is performed to enhance the original file system 

applications such as word processing, e-mail and spread- 25 ca U and the file system call is transparently returned to the 

sheet applications write temporary files during operation. calling system application. In one embodiment, real-time 

Although these applications typically automatically delete secu J" e file deletion is implemented using a vendor supplied 

the temporary files, they do so using an insecure file deletion driver (VSD) executing within the installable file system 

method leaving traces of the files on the hard drive or other QFS) of WINDOWS 95. 

storage device. Virtual memory files, such as swap files, also 30 According to another aspect of the present invention, a 
cause a problem in that file fragments are swapped in and out method and system are disclosed for real-time secure data 
the virtual memory files during operation. The fact that deletion in a system having an NTFS file system. Read calls 
information is thus available on a storage device despite are monitored using a read filter and pointers to NTFS 
having apparently been deleted generates a security risk that metafiles and page files are recognized and stored. Write 
is unacceptable to many individuals and public and private 35 calls are monitored using a write filter and real-time secure 
organizations. data deletion of buffers is performed. File creation opera- 
One method for alleviating this problem is simply to uons are monitored and real-time secure data deletion of 
physically destroy the storage device such that any data user files k performed when the file is to be overwritten, 
stored thereon is unrecoverable. However, this is an under- ^ Further, set information operations are monitored and real- 
standably expensive and time consuming solution. As an time secure data deletion is performed for truncated, shrunk 
alternative to physical destruction of the storage device, or de) eted user files. 

conventional secure file deletion products provide targeted A technical advantage of the present invention is the 
secure file deletion functions. Examples of conventional interception of file system calls such that supplemental file 
products include NUKER (available from GENIO USA), 45 management processes can be performed in a manner trans- 
Mi CROZAP (available from NEW TECHNOLOGIES parent not only to the user but also to the operating system. 
INC.), BUR NIT (available from SYNCRONYS Another technical advantage of the present invention is 
SOFTCORP) and SECUREWIN (available from CIPHER that secure file deletion is performed real-time on an ongo- 
LOGICS CORPORATION). ing basis transparently to the user of the system. Thus, 
In general, "secure" deletion involves overwriting the 50 secure deletion of files on storage devices is accomplished 
appropriate space on the storage device with specified without relying upon periodic actions by the user, 
overwrite arrays to obscure the original data. The overwrite A further technical advantage of the present invention is 
arrays can be random or pseudo-random data as well as that, for write calls, overhang of data in the existing file on 
defined character or data patterns. Further, a series of the storage device is identified and overwritten as part of the 
overwrites can be performed in sequence with different 55 real-time secure deletion process. 

specified arrays to ensure that the data can not be recovered Another technical advantage is that secure deletion of 

even by destructive analysis of the fixed storage media. buffers, user files and other data in a WINDOWS NT file 

Conventional targeted secure deletion products allow a user system are automatically handled. 

to select a file for deletion and then securely delete that file. Additional technical advantages should be readily appar- 

Such products can also allow a user to secure delete all free 60 ent from the drawingS) description, and claims, 
media space on a storage device. Also, conventional secure 

delete products may allow a user to secure delete virtual BRIEF DESCRIPTION OF THE DRAWINGS 

memory files (e.g., swap files). A more complete understanding of the present invention 

However, conventional secure file deletion products suffer and advantages thereof may be acquired by referring to the 

from a number of problems. One problem is that the targeted 65 following description taken in conjunction with the accom- 

nature of the conventional products relies upon user activa- panying drawings in which like reference numbers indicate 

tion of the process. Further, the user only executes the secure like features and wherein: 
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FIG. 1 is a flow chart of one embodiment of a method for ensure real-time secure file deletion on the storage device, 

enhancing file system calls to a file system structure of an One implementation of supplemental processing to ensure 

operating system according to the present invention; secure file deletion is provided by FIGS. 4-8. According to 

FIG. 2 is a diagram of the file system logical layers of the the present invention, the supplemental processing of step 
WINDOWS DS operating system; 5 1** can De accomplished transparently both to the user and to 

FIG. 3 is a diagram of a typical'file system request chain the calUn e ^ stem application. After the supplemental 

within the file system logical layers of the WINDOWS 95 Processing, the call ,s returned, in step 18, to the calling 

operating system; s y stem a PP llcatl0n - 

FIG. 4 is a flow chart of one embodiment of supplemental ™" i^-f *j e Sy f °u 

processing after interception of a delete call according to the 10 WINDOWS 95 instaUable file system (IPS) The installable 

present invention* fiIe s y stem 15 described, for example, in "Examining the 

^ n * „ 1 . _ 1 Windows 95 Layered File System: Adding Functionality to 

FIG. 5 is a flow chart of one embodiment of supplemental Block Devices » Mark Russinovich and B ryce Cogswell, 

processing after interception of a wnte call according to the 1997 [http://wwWtddj . OTm/ddj/ i99 5/ i995.i2/russinov.htm 

present invention; 15 ^ Q f Sep. 4, 19973]. As shown in FIG. 2, the installable file 

FIG. 6 is a flow chart of one embodiment of supplemental system is made up of thirty two logical layers, each con- 
processing after interception of an open (create always) call taking one or more virtual devices through which block- 
according to the present invention; device requests pass. For typical hardware, most of the 

FIG. 7 is a flow chart of one embodiment of supplemental logical layers are empty. For example, for hard disk drives, 

processing after interception of a rename call according to 20 a file system request (or call) will usually only pass through 

the present invention; and about five virtual devices on the way to the hardware. 

FIG. 8 is a flow chart of one embodiment of overwriting FIG. 3 is a diagram of a typical file system request chain 
a filename according to the present invention; or path within the file system logical layers of the WIN- 
FIG. 9 is a block diagram of components of the WIN- DOWS 95 operating system. As shown in FIG. 3, a typical 
DOWS NT I/O system* P atD begins at the IFS manager 22 and moves to the file 

FIG. 10 is a block diagram of NTFS a D d related executive system driver 24. The request then moves to a type specific 

driver 26 and a vendor supplied driver 28. After vendor 

P ' supplied driver 28, the request falls to a port driver 30 and 

FIG. 11 is a block diagram of the NTFS object model; tQ ^ hard ^ 32 (of Qthcr storage deyice) ^ the 

FIG. 12 is a flow chart of one embodiment of a process for 30 requcst ^ com pleted at the physical level, the request returns 
an NTFS read filter for real-time secure data deletion under up me CQa ] n to tnc calling system application. 

In FIG. 2, the numbers on the left hand side represent the 
FIG. 13 is a flow chart of one embodiment of a process for layers of abstraction with the smallest numbers representing 
NTFS read filter for real-time secure data deletion; higher layers of abstraction. The topmost layer is the entry 

FIG. 14 A is a flow chart of one embodiment of a process point to the file system. Higher numbers are closer to the 
for real-time secure data deletion of NTFS user files; hardware, and the highest number (bottom layer) represents 

F1G.14B is a flow chart of additional steps for the process the virtual devices that access the hardware directly. An 
of FIG. 14A. input/output (I/O) supervisor (IOS) manages requests as 

m they pass through the file-system hierarchy. Each virtual 
DETAILED DESCRIPTION OF THE w device on the chain can select requests based on the logical 

INVENTION or physical drive to which the request is directed. The device 

FIG. 1 is a flow chart of one embodiment of a method for 3 Cao also view result of a 45 { [ P^ 5 U P 

enhancing file system calls to a file system structure of an lhe chain to th f application. Furthermore, the virtual device 

operating system according to the present invention. The 45 drivers (VxDs) on the cham can service requests themselves 

method of FIG. 1 can be implemented, for example, by a DOt P 355 them t0 lower levels > or can g enerate 

software driver executing within the file system established requests themselves. 

by the operating system of a personal computer, computer Processes can occur at each level of the installable file 
workstation or other computing device. For example, the system, but most block devices do not require an entry at 
method of FIG. 1 can be implemented using a vendor so each level in the chain. At the top of the logical layer 
supplied driver (VSD) executing within the installable file structure, the IFS manager layer manages high-level I/O 
system (IFS) of WINDOWS 95. requests from applications. It takes a call directed at a 
As shown in FIG. 1, in step 10, a file system call is specific logical drive and passes it down the correct call- 
intercepted. In general, the file system call is intended to down chain to the appropriate volume tracker, file system 
perform some function with respect to data stored on a 55 driver (FSD), and so on. Volume trackers work with groups 
storage device but is intercepted before being able to com- of devices with identical removability rules. For example, a 
plete that function. The storage device can be a hard disk CD-ROM volume tracker ensures that a CD with a file 
drive, a ZIP drive, floppy drive, tape drive, writeable CD svstem 011 il is in the drive before [i ^ l ^ ov < ^ requests 
ROM drive or other fixed or removable storage media. The to pass through to lower layers. File system drivers (FSDs) 
file system call can be, for example, a file system delete, 60 work with all devices of a particular type, such as hard disks 
write, open, rename, close, read or other file system call. In or CD-ROM devices. They take incoming logical requests 
step 12 of FIG. 1, it is determined whether the type of call generated by the IFS manager and translate them into 
intercepted is one that should be processed. If not, then in physical requests to pass to lower levels. In addition, FSDs 
step 14, the original call is passed on through the file system. can initiate logical error recovery for devices such as disks. 
If tie call should be processed, then in step 16, supplemental 65 Type specific drivers (TSDs) work with all devices of a 
processing is performed to enhance the original call. In particular type. They take a logical request generated by an 
particular, in step 16, the original call can be enhanced to FSD and translate it into a physical sector request. They 
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generally reside in the same layer as their corresponding the these calls occurs in step 10 of FIG. 1. The above calls 

FSDS, but are lower in the chain. SCSI-izers are next in the are ten identified, in step 12, as ones for which supplemental 

chain and are used because SCSI devices require more- processing will be performed. Supplemental processing then 

complex request packets than other devices such as the occurs within step 16 of FIG. 1. 

more-prevalent IDE/ESDI devices. SCSI-izers take a gen- 5 FIG. 4 is a flow chart of one embodiment of supplemental 

eral physical request and create a SCSI Request Block processing after interception of a delete call according to the 

(SRB) that contains detailed, SCSI-specific information present invention. In step 34, the driver opens a handle to the 

about the request such as the Logical Unit Number (LUN) file identified in the delete call, and in step 36, the driver 

and Target (SCSI targets can have up to seven LUNs ret l uests me size of the file - ™ en m ste P me dnver 

hanging off them). 10 ove rw" les tne n ^ e with a specified overwrite array. The 

T , , , ' v . , . , . specified array can be any desired pattern of characters or 

Vendor supplied drivers (VSDs) provide a special layer /, « J u A i , /- u . , fi , 

r xu- j * j i 1 u;TxrriA«rc ner data and can be user defined or default to a pre-defined 

for third-party developers under WINDOWS 95. T . Afl , . f * . 

^ Z iL wow^ . rL - j. pattern. In step 40, the driver generates a force commit to 

Consequently, the VSD layer functionality is determined by j. , . a . t , & c lL . j • j 

■! ^ . • i j , j ■ disk to flush the write buffer of the storage device and ensure 

the VSD writer. Conventional uses include: block-device . <u • -T^ n tn m ~A^ t„ 

. . . . ,. , ./ that the overwrite array is actually written to the media. In 

monitors, ow-level secondary disk caches (caching in flash « overwri(es 

moment' ' encr yP tl0n > and should be performed. If so, the driver returns to step 38. 

managemen . Etch overwr jt6 iteration can use a different overwrite array 

SCSI port drivers take incoming requests and determine to attaio mcr easing levels of security. For example, the 

which SCSI miniport driver should field them. Multiple overwrite arrays can cause each storage location to alterna- 

SCSI types can be loaded onto the same system, each of tivcly be to a «o" ^ a «i» t o obscure the original 

which may require a custom SCSI miniport driver. The SCSI d ata stored at mat i ocat ion. In some implementations, there 

port driver is also in charge of initializing the miniport are seven overwrite iterations to ensure that the original data 

drivers. SCSI miniport drivers (MPDs) are the hardware is securely deleted even if analyzed using destructive testing 

drivers for SCSI devices. They manage the interrupt and I/O md advanced detection equipment. 

port-level interaction with the device to carry out requests ^ thc overwrite proce ss is complete, the driver closes 

from above. They can also perform adapter-specific error ^ handle tQ ^ fik ^ step 44 In step 46 the driver logs 

recovery. me p rocess j ust completed to an in-memory log. The 

Port drivers (PDRs) (for non-SCSI hardware) carry out in-memory log can be periodically written to the storage 
analogous functions as the SCSI port and miniport drivers. 3Q device as a log file. In step 48, the driver passes the original 
They provide 32-bit disk access interacting directly with the delete ca n down me file system layers such that the proper 
hardware to perform I/O. The real mode mapper (RMM) is fl ags get for the system to consider the delete to have 
used in certain situations where WINDOWS 95 can not properly completed. In step 50, the driver then overwrites 
provide a port drive. With the introduction of plug-and-play the filename of the file just deleted. One embodiment of 
BIOS, and by including many hardware-specific port 35 overwriting the filename is shown in and described with 
drivers, WINDOWS 95 can usually provide 32-bit access for respect to FIG. 8. After overwriting the filename, in step 52, 
most disk hardware. However, Windows 95 might be run on the driver modifies the original delete call to make it a get 
an older personal computer with esoteric hardware, so it fii e attribute call and passes the new call down the file 
must make allowances for the case where it can not provide system layers. In step 54, the get file attribute call completes 
a port driver to handle disk I/O in protected mode. A system ^ and returns to the calling system application, 
might also use real-mode disk-driver software that provides FIG. 5 is a flow chart of one embodiment of supplemental 
functionality not available in the WINDOWS 95 protected- processing after interception of a write call according to the 
mode counterpart.-For these situations, the last entry on the preS ent invention. For the write call, the call is intercepted 
chain of protected-mode virtual device drivers is an RMM ^ captur ed by the driver only if the write has a length of 
instead of a port driver. RMMs call down to a real-mode 45 ^ This md i cates tnat the write call is placing the end- 
driver to perform hardware I/O and return results up the of _^ e (EOF) marker after the contents of the file have 
file-system chain. Real-mode drivers are hardware drivers already been written to the storage device. After interception 
required by the hardware or software configuration of a of a wrfte call ^ length irj step 56j me 
particular system. However, use of real-mode drivers is determines the position for the end-of-file (EOF) marker 
discouraged because performance can suffer (due to the 5Q directly from the write call. In step 58, the driver obtains the 
overhead of transitions from protected to real mode and true file size of me me m eQU merate handle function, 
slower execution in real mode), but makes allowances for ^ step 60 me driver determines the overhang, if any, 
them for flexibility and backward compatibility. of the filc bascd upon me ^ file size and ^ pos ition of the 

In general, the upper, layers of the file system structure are new EOF marker. The overhang is the portion of the file that 

written by MICROSOFT as part of WINDOWS 95, while ss existed prior to the write that would extend past the new 

the lower layers are provided by disk-drive manufacturers. EOF marker. 

Consequently, the layer typically used for development by \ n ste p 62, the driver overwrites the overhang with a 

third-party developers is the virtual device driver (VSD) specified overwrite array. As was described above, the 

layer. As mentioned above, according to the present overwrite array can be user-defined or pre-defined and is 

invention, a VSD can be used to intercept file system calls 60 designed to obscure the original data stored in the storage 

and perform supplemental processing. In particular, the files device. In step 62, the driver performs the overwrite by 

system calls can be enhanced to ensure real-time secure file directing the original intercepted write call to the file system 

deletion. with changed parameters such that the overhang is over- 

In one implementation of the present invention, a vendor written. Then, in step 64, the driver determines whether 

supplied driver is used to intercept file system delete, write, 65 additional overwrites should be performed. If so, the appli- 

open (create always) and rename calls and to provide the cation returns to step 62. Successive iterations of overwrites 

real-time secure file deletion functionality. Interception of can use different overwrite arrays to better ensure secure 
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deletion as described above. After overwriting the overhang, 
the driver logs the process in the in-memory log which can 
be periodically written to the storage device. Then, in step 
70, the driver passes the original write call down the file 
system layers to place the EOF marker as originally 5 
intended. In step 72, this write call completes and returns to 
the calling system application. 

FIG. 6 is a flow chart of one embodiment of supplemental 
processing after interception of an open (create always) call 30 
according to the present invention. An open (create always) 
call is one that opens a file and, in doing so, always creates 
a new file rather than simply opening the existing file. This 
means that the old file still exists on the storage device and 15 
may not be overwritten by the newly created file. After 
interception of the open (create always) call, the driver 
directs a "ring zero" open call through the file system. A 
"ring zero" call is one that process down from the IFS 
manager through the entire file system logical layer struc- 20 
ture. Thus, the ring zero open call will be passed back to the 
driver. 

In step 76, the driver determines whether a handle for the 
file is returned. If a handle is returned, it indicates that the 25 
file exists, otherwise the file is a new file. If a handle is 
returned, then the handle is closed and, in step 78, the driver 
directs a ring zero delete call for the existing file. This delete 
call is passed back to the driver and intercepted as with other 3Q 
delete calls such that processing continues at step 14 of FIG. 
4. If it is determined in step 76 that a handle was not 
returned, then the driver passes the original open (create 
always) call down the file system layers in step 80. In step 
82, the original open call completes and returns to the 35 
system application. 

FIG. 7 is a flow chart of one embodiment of supplemental 
processing after interception of a rename call according to 
the present invention. In step 84, the driver opens a handle 40 
to the file. Opening a handle to the file provides information 
about the file which is returned in the file open block 
structure. This information is needed to perform the over- 
write filename process of FIG. 8 and is described below. In 
step 86, the driver closes the handle to the file, and then, in 45 
step 88, logs the process to the in-memory log. The driver 
passes the original rename call down the file system layers 
in step 90. Then, in step 92, the driver overwrites the old 
filename, for example, according to the process of FIG. 8. In 50 
step 94, the driver modifies the original rename call to a get 
attribute call and passes the get attribute call down the file 
system layers. In step 96, the get attribute call completes and 
returns .to the calling system application. 

FIG. 8 is a flow chart of one embodiment of overwriting 55 
a filename according to the present invention. The process of 
FIG. 8 ensures that deleted filenames are overwritten and 
organizes active filenames within the directory structure. 
Prior to starting the process of FIG. 8, the driver has 6Q 
information about the file based upon having opened a 
handle to the file. In particular, the file open block structure 
provides the starting sector for the directory entry of the 
filename and the starting cluster of the directory structure. 
The following table sets forth the position of this informa- 65 
tion within the file open block structure for WINDOWS 95 
GOLD and OSR2 versions. 
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OFFSET & LABEL 

OFFSET & LABEL 


GOLD 95 

OSR2 

COMMENT 

40 DWORD d40 

IS DWORD dl8 

starting sector for 



dircctoiy entry of 



filename 

50 DWORD 

1C DWORD d20 

starting cluster of 

sector pos 


directory structure 


This starting sector and starting cluster information is used 
by the driver to locate and overwrite filenames. 

In step 98 of FIG. 8, the driver reads sector zero (the boot 
parameter block) of the logical drive to obtain information 
about the geometry of the logical drive. Then, in step 100, 
the driver determines the file allocation table (FAT) structure 
and other information about the logical drive. In step 102, 
the driver reads the cluster that contains the directory 
structure containing the filename to be overwritten. The 
correct cluster can be determined using the starting cluster of 
directory structure obtained from the file open block struc- 
ture as shown in the above table. 

After the cluster has been read, in step 104, the driver 
parses the directory structure within the cluster to process 
each field within the directory structure. The directory 
structure contains sequentially positioned fields for filena- 
mes that each consume, for example, 32 bytes of storage. In 
step 106, if the driver encounters an active filename, the 
driver rebuilds the directory structure by adding the active 
filename. In step 108, if the driver encounters a deleted 
filename, the driver overwrites the deleted filename with a 
specified overwrite array. As described above, the overwrite 
array can be a user-defined or pre-defined pattern designed 
to obscure the original data. Further, the overwriting of step 
108 can involve one or multiple overwrites to provide 
varying levels of secure deletion. 

In step 110, the driver checks whether it has reached the 
specific sector or filename that initiated the overwrite. If so, 
the filename overwrite process continues at step 114. If not, 
in step 112, the driver checks whether it has finished the 
entire directory structure. If so, the process continues at step 
114. If not, the driver determines the next cluster for the 
directory structure in step 116, and the driver reads in the 
structure in step 118. Then, the process returns to step 104 
to continue parsing the directory structure. After the file- 
name has been overwritten, in step 114, the driver forces an 
absolute disk write of the rebuilt cluster containing the 
active filenames to ensure that the data is actually written to 
the storage device. 

According to the above implementation of the present 
invention, the file system delete, write, open (create always) 
and rename calls are intercepted and processed to provide 
secure file deletion. This secure file deletion is performed 
real-time on an ongoing basis transparently to the user of the 
system. Thus, secure file deletion is accomplished without 
relying upon periodic actions by the user. 

FIG. 9 is a block diagram of components of the WIN- 
DOWS NT I/O system, indicated generally at 120. As 
shown, I/O system 120 includes a number of components 
referred to as the NT executive 122. Within NT executive 
122, there is NT system services 124 and I/O manager 126 
as well as other components. I/O manager 126 can interface 
with a storage device such as a disk drive 128. As shown, 
these components of I/O system 120 are part of the kernel 
mode of WINDOWS NT. In the user mode, there can be an 
environment subsystem or dynamic linked library (DLL) 
130 that interfaces with NT system services 124. 
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In WINDOWS NT, the NT file system (NTFS) and other of attributes. NTFS uses the same read routine regardless of 

file systems are loadable drivers. They can be added to or whether it is reading a file's data attribute, its security 

removed from the operating system AS they are needed. All descriptor attribute, its file name attribute, or any of the file's 

drivers then work within the context of I/O system 120 and other attributes. Similarly, when writing to a file, NTFS 

are invoked indirectly by applications that use Win32 or 5 takes an attribute as a parameter and writes to that attribute. 

other I/O application program interfaces (APIs). As shown Because *ese object routines are generic, they are designed 

in FIG. 9, the environment subsystems 130 call NT system l ° ^ accommodate new attributes that may be added in 

services 124, which in turn locate the appropriate loaded tnctuturc. kTTT ™ . ... , A , 

a ' 11 >k« m The structure of NTFS begins with a volume. A volume 

drivers and call tnem. , , , . ..f. ... , # - . , 

™« 1A . i j ■ fvTTCP i i * j *• „ corresponds to a logical partition on a disk, and it is created 

FIG. 10 is a block diagram of NTFS and rehted executive 10 when * format % ^ * of a ^ AvQlume 

components. As shown, the log file service (LPS) 132 is a of a ^ of m&& ]us additional una u ocat ed 

module of NT executive 122 that provides services for remaining on the disk partition. In the FAT file system 

maintaining a log of disk writes. The log file it writes is used ^ HPFS a volume ^ areas specialty formatted 

to recover an NTFS-formatted volume in the case of a for use by the file system. An NTFS volume, however, stores 

system failure. The cache manager 134 is a component of 15 ^ ^ S y S tem data, such as bitmaps and directories, and 

NT executive written 134 that provides system-wide caching even lne system bootstrap, as ordinary files. NTFS is like the 

services for NTFS and other file system drivers, including FAT file system in that it uses the cluster as its fundamental 

network file system drivers (servers and redirectors). All file unit of disk allocation. 

systems implemented for WINDOWS NT access cached The cluster size on a volume, or cluster factor, is estab- 

files by mapping them into virtual memory and reading and 20 lished by the NTFS Format utility when a user formats the 

writing to virtual memory. Cache manager 134 provides a volume. Internally, NTFS refers only to clusters and is 

specialized file system interface to the WINDOWS NT unaware of a disk's sector size. NTFS refers to physical 

virtual memory manager (VM manager) 136 fgr this pur- locations on a disk by means of logical cluster numbers 

pose. When a program tries to access a part of a file that is (LCNs). LCNs are simply the numbering of all clusters from 

not loaded into the cache (a cache miss), VM manager 136 25 the be ginning of the volume to the end. To convert an LCN 

calls NTFS to access the disk driver and obtain the file to a physical disk address, NTFS multiplies the LCN by the 

contents from disk. Cache manager 134 optimizes disk I/O cluster factor to get the physical byte offset on the volume, 

by using its lazy writer, a set of system threads that calls VM as the disk driver interface requires, 

manager 136 to flush cache contents to disk as a background As mentioned above, NTFS maintains a file called the 

activity (asynchronous disk writing). 30 master file table (MFT), which is the heart of the NTFS 

The relationships shown for NTFS in FIG. 10 are gener- volume structure. Logically, the MFT contains one row for 

ally the same as those for the other Windows NT-supported each file on the volume, including a row for the MFT itself, 

file systems: the FAT file system, HPFS, and network file In addition to the MFT, each NTFS volume contains a boot 

systems. The only difference is that these file systems do not file and a set of files containing data called metadata or 

call the log file service to log transactions. 35 metafiles that is used to implement the file system structure, 

FIG. 11 is a block diagram of the NTFS object model, The rest of the files on an NTFS volume are normal user files 

indicated generally at 140. As shown, the object model 140 and directories. The MFT is implemented as an array of file 

includes object manager data structures 142, NTFS data records. An MFT "row," representing one file on the disk, 

structures 144 and NTFS database 146. In generally, NTFS usually consists of one file record. However, if a file has a 

participates in the WINDOWS NT object model by imple- 40 large number of attributes or becomes highly fragmented, 

menting files as objects. This allows files to be shared and more than one file record might be needed. In such a case, 

protected by the object manager. An application creates or the first record, which stores the locations of the others, is 

accesses a file just as it does other NT objects: by means of called the base file record. A file on an NTFS volume is 

object handles. By the time an I/O request reaches NTFS, the identified by a 64-bit value called a file reference. The file 

WINDOWS NT object manager and security system have 45 reference consists of a file number and a sequence number, 

already verified that the calling process has the authority to The file number corresponds to the position of the file's file 

access the file object in the way it is attempting to. The I/O record in the MFT minus one (or to the position of the base 

manager has also transformed the file handle into a pointer file record minus one if the file has more than one file 

to a file object. NTFS uses the information in the file object record). The file reference sequence number, which is incre- 

to access the file on disk. 50 mented each time an MFT file record position is reused, 

FIG. 11 illustrates the data structures that link the enables NTFS to perform internal consistency checks, 

memory-based object architecture to the file system's FIG. 12 is a flow chart of one embodiment of a process for 

on -disk structure. NTFS is called with a pointer to a file an NTFS read filter for real-time secure data deletion under 

object. It follows several pointers to get from the file object NTFS. This process provides a read filter for monitoring 

to the location of the file on disk. As shown, a file object, 55 read calls in order to recognize and hold pointers to NTFS 

which represents a single call to the open-file system service, metadata and the page file. These files can be recognized by 

points to a stream control block (SCB) for the file attribute the absence of a file name and the content of the buffer. As 

that the caller is trying to read or write. In FIG. 11, a process shown in FIG. 12, in step 150, the process determines 

has opened both the data attribute and a user-defined whether or not the disk volume is a FAT volume. If so, the 

attribute for the file. The SCBs represent individual file 60 process exits. If not, the process continues at step 152 and 

attributes and contain information about how to find specific determines whether or not the volume is an NTFS volume, 

attributes within a file. All the SCBs for a file point to a If not, the process exits. If the volume is an NTFS volume, 

common data structure called a file control block (FCB). The the process continues at step 154. In step 154, the process 

FCB contains a pointer (actually, a file reference) to the file's determines whether or not the read call is through system I/O 

record in the disk-based master file table (MFT). 65 call. If not, in step 156 the process determines whether or not 

NTFS views a file as a collection of attributes, just as the the call is to a page file. If not, the process exits. If so, the 

Windows NT object manager views an object as a collection process stores the page file object in step 158 and exits. 
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Returning to step 154, if the call is through system I/O, the 
process continues at step 160 and determines whether the 
call involves the master file table (MFT) buffer. If so, the 
process stores the metafile object in step 162 and exits. If 
not, the process continues at step 164 and determines 
whether or not the call involves a log or restart buffer. If so, 
the process stores the metafile object in step 162 and exits. 
If not, the process determines, in step 166, whether the call 
involves an index buffer. If not, the process exits. If so, the 
process continues at step 168 and determines whether or not 
cached information is found for that directory, if so, the 
process stores the metafile object in step 162 and exits. If 
not, the process reads the master file table record for the 
directory in step 170, and then stores data run in bitmap 
attributes in step 172. After step 172, the process stores the 
metafile object in step 162 and exits. 

FIG. 13 is a flow chart of one embodiment of a process for 
NTFS read filter for real-time secure data deletion. This 
process provides a write filter on NTFS metadata and FAT 
index files. These files can be recognized by the absence of 
an associated file name and the content of the buffer, As 
shown in FIG. 13, in step 180, the process determines 
whether or not the volume is a FAT volume. If so, the 
process determines, in step 182, whether the buffer is a 
directory buffer. If not, the process exits. If so, the process 
spot shreds the buffer to specification in step 184. The term 
"shred" is used to mean that data is securely deleted in 
real-time such that the data is unrecoverable. Step 184 thus 
involves real-time secure deletion of the data, for example, 
by overwriting the data with specified patterns to make it 
unrecoverable in a manner analogous to that described 
above. Shredding to specification involves following a 
specified number of overwrites with specified overwrite 
patterns. 

In step 180, if the volume is not a FAT volume, the process 
continues in step 186 and determines whether the volume is 
an NTFS volume. If not, the process exits. If the volume is 
an NTFS volume, the process continues at step 188 and 
determines whether the buffer is a master file table buffer. If 
so, the process determines, in step 190, whether there is a 
directory entry. If not, the process spot shreds the buffer to 
specification in step 192 and exits. If there is a directory 
entry, the process loads the data run and bitmap attributes in 
step 194. Then, in step 196, the process determines whether 
the bitmap is changed. If not, the process spot shreds the 
buffer to specification in step 192 and exits. If so, the process 
block shreds index clusters in step 198, and then returns to 
step 192 to spot shred the buffer to specification. 

Returning to step 188, if the buffer is not an MFT buffer, 
the process determines in step 200 whether the buffer is an 
index buffer. Is so, the process spot shreds the buffer to 
specification in step 192 and exits. If not, the process 
determines whether or not the buffer is a log buffer in step 
202. If so, in step 204, the process determines whether 
real-time log shredding has been selected. If not, the process 
exits. If so, the process saves the offset and length of write 
to the current control set in step 205 and exits. 

Returning to step 202, if the buffer is not a log buffer, the 
process determines whether it is a restart record buffer in 
step 206. If not, the process exits. If so, the process 
determines, in step 208, whether or not real-time log shred- 
ding has been selected. If not, the process exits. If so, the 
process determines in step 210 whether a previous control 
set was saved. If so, the process block shreds the previous 
control set and moves to step 214. If not, the process moves 
directly to step 214. In step 214, the process shifts the 
current control set to the previous control set and clears the 
current control set. Following step 214, the process exits. 
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FIG. 14A is a flow chart of one embodiment of a process 
for real-time secure data deletion of NTFS user files. The 
process of FIG. 14 is initiated in several ways. The first 
occurs when a user file is opened with overwrite intentions. 

5 The second occurs when a file is deleted, and the third occurs 
when end-of-file is set below the existing end-of-file. This 
process can handle both NTFS and FAT user file shredding. 

As shown in FIG. 14A, the process determines whether an 
operation is a file creation operation in step 220. If so, in step 

10 222, the process determines whether it is a file overwrite. If 
so, the process shreds the file to specification in step 224. If 
not, the process exits. 

Returning to step 220, if the operation is not a file creation 
operation, the process determines, in step 226, whether it is 

is a set information operation. If so, the process gets the 
existing file allocation size and end-of-file in step 228. Then 
in step 230, the process sets a variable "x" equal to zero, and 
a variable "Y" equal to the allocation size. In step 232, the 
process determines whether the set information operation is 

20 for allocation. If so, in step 234, the process determines 
whether the old end-of-file is greater than zero and whether 
the new allocation is equal to zero. If not, the process exits. 
If so, the process sets a "shred action" equal to "truncate" in 
step 236. Then, in step 238, the process queues the shred 

25 action to a shred thread (file shred). 

From the queue, in step 240, the process determines 
whether there is an NTFS volume, the shred action is equal 
to "delete," and there is a known MFT metafile object. If not, 
the process exits. If so, the process gets the MFT record 

30 number of the user file in step 242. Then in step 244, the 
process reads the MFT record of the file and, in step 246, the 
process gets the MFT record number of the parent directory. 
Following this, in step 250, the process locates the cached 
data run and bitmap attributes. In step 252, the process 

35 determines whether cached information was found. If not, 
the process exits. If so, the process reads the MFT record of 
the parent directory in step 254 and continues at step 270 of 
FIG. 14B (described below). 

Returning to step 232, if the set information operation is 

40 not an allocation, the process determines, in step 256, 
whether the operation is an end-of-file operation. If so, the 
process determines, in step 258, whether the old end-of-file 
is greater than the new end-of-file. If not, the process exits. 
If so, the process sets the shred action equal to "shrink" and 

45 sets "x" equal to the new end-of-file. The process theo 
queues the shred action to the shred thread in step 238, 
which proceeds at step 240 as described above. 

If, in step 256, the operation is not an end-of-file 
operation, the process determines, in step 266, whether the 

so operation is a delete disposition operation. If not, the process 
exits. If so, the process checks whether the old end-of-file is 
greater than zero in step 264. If so, the process sets the shred 
action to "delete" in step 266 and proceeds to step 238. If 
not, the process exits. 

55 FIG. 14B is a flow chart of additional steps for the process 
of FIG. 14A. Step 270 follows step 254 of FIG. 14A. As 
shown, in step 270, the process compares the old and new 
bitmaps. The process then determines, in step 272, whether 
there is a difference between the bitmaps. If not, the process 

60 exits. If so, the process gets a list of all cluster offset/length 
pairs where differences exist in step 274. These pairs are 
then processed. In step 276, the process determines whether 
there are pairs to process. If not, the process exits. If so, the 
process determines, in step 278, whether the offset/length is 

65 within the existing cache. It should be noted that, as files are 
deleted from a directory, the cache containing the index data 
may shrink if all of the files in a group of clusters at the end 
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of the cache have been deleted. Id this case, NTFS does not 
rewrite the index buffers, and it is sometimes necessary to 
shred them directly on disk. If the offset/length is within the 
existing cache, the process flushes the cache at that offset in 
step 280. It should be noted that in this case, a group of 
clusters containing index data are no longer needed because 
the files named within have all been deleted. The clusters 
still exist in cache because they are somewhere in the middle 
of the cached data, and there are other clusters beyond them 
which contain existing file names, In this case, the cache can 
simply be flushed, and the shredding to specification can 
occur when the write is filtered by the volume write filter 
flow discussed above. If, in step 278, the offset/length is not 
within the existing cache, the process opens the volume, in 
step 282, and shreds to specification at that location. After 
step 280 or 282, the process returns to step 276 to determine 
whether there are more pairs to be processed. If not, the 
process exits. 

Although the present invention has been described in 
detail, it should be understood that various changes, substi- 
tutions and alterations can be made hereto without departing 
from the spirit and scope of the invention as defined by the 
appended claims. 

What is claimed is: 

1. A method for real-time secure file deletion in a system 
having an NTFS file system, comprising: 

monitoring read calls using a read filter and recognizing 
and storing pointers to NTFS metafiles and page files; 

monitoring write calls using a write filter and performing 
real-time secure data deletion of buffers; 

monitoring file creation operations and performing real- 
time secure data deletion of buffers; 

monitoring set information operations and performing 
real-time secure data deletion for truncated, shrunk or 
deleted user files; 

wherein performing real-time secure data deletion com- 
prises overwriting data for a specified number of 
iterations, each iteration using a specified overwrite 
array; and 

monitoring the file system to determine whether addi- 
tional data overwriting is required for complete data 
deletion, including the deletion of any traces of said 
data remaining during or after the deletion process. 

2. The method of claim 1, wherein monitoring of read 
calls comprises: 

storing a page file object in response to recognizing a page 
file; 

storing a metafile object responsive to recognizing a 
master file table buffer; 

storing a metafile object responsive to recognizing a log 
or restart buffer; and 

storing data run and bitmap attributes responsive to rec- 
ognizing an index buffer and locating cached informa- 
tion for the directory. 

3. The method of claim 2, wherein monitoring of write 
calls comprises: 

performing spot real-time secure data deletion of the 
buffer responsive to identifying a master file table 
buffer without a directory entry; 

performing spot real-time secure data deletion of the 
buffer responsive to identifying a master file table 
buffer without a directory entry and performing block 
real-time secure data deletion of index clusters if bit- 
map attributes have been changed; 

performing spot real-time secure data deletion of the 
buffer responsive to identifying an index buffer. 
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4. A system for real-time secure data deletion in a system 
having an NTFS file system, comprising: 
a storage device; 
a memory; and 

a processor, the processor executing an operating system 
that provides a file system for managing data on the 
storage device, and the processor executing a driver 
within the file system such that the apparatus operates: 
to monitor read calls using a read filter and recognize 
and store pointers to NTFS metafiles and page files; 
to monitor write calls using a write filter and perform 

real-time secure data deletion of buffers; 
to monitor file creation operations and perform real- 
time secure data deletion of user files when the file 
is to be overwritten; 
to monitor set information operations and perform 
real-time secure data deletion for truncated, shrunk 
or deleted user files; and 
to monitor the file system to determine whether addi- 
tional data overwriting is required for complete data 
deletion, including the deletion of any traces of said 
data remaining during or after the deletion process. 
. 5. The system of claim 4, wherein to monitor read calls 
comprises: i 

storing a page file object in response to recognizing a page 
file; 

storing a metafile object responsive to recognizing a 
master file table buffer, 

storing a metafile object responsive to recognizing a log 
or restart buffer; and 

storing data run and bitmap attributes responsive to rec- 
ognizing an index buffer and locating cached informa- 
tion for the directory, 

6. The system of claim 5, wherein to monitor write calls 
comprises: 

performing spot real-time secure data deletion of the 
buffer responsive to identifying a master file table 
buffer without a directory entry; 

performing spot real-time secure data deletion of the 
buffer responsive to identifying a master file table 
buffer with a directory entry and performing block 
real-time secure data deletion of index clusters if bit- 
map attributes have changed; 

performing spot real-time secure data deletion of the 
buffer responsive to identifying an index buffer. 

7. A method for enhancing file system calls to a file system 
structure of an operating system, comprising: 

intercepting a file system call, the file system call intended 
to perform a function with respect to data stored on a 
storage device; 

determining whether the file system call is of a type that 
should be processed; 

if the file system call should not be processed, passing the 
file system call on through the file system; and 

if the file system call should be processed, performing 
supplemental processing to enhance the file system call 
and transparently returning the file system call to a 
calling system application; 

wherein the supplemental processing enhances the file 
system call to provide real-time secure file deletion on 
the storage device, and with said real-time secure file 
deletion occurring at substantially the same time as said 
file system call performs said function with respect to 
data stored on said storage device. 
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8. The method of claim 7, wherein the method is imple- 
mented using a vendor supplied driver (VSD) executing 
within the installable file system (IFS) of WINTDOWS 95. 

9. The method of claim 8, wherein the file system call is 
from the group consisting of a delete call, a write call, an 5 
open (create always) call and a rename call. 

10. The method of claim 9, wherein the supplemental 
processing is based upon the type of file system call inter- 
cepted. 

11. The method of claim 10, wherein if the intercepted file 10 
system call is a delete call, the supplemental processing 
comprises: 

opening a handle to a file identified in the delete call; 
requesting a size of the file; 

overwriting the file with a specified overwrite array; 
generating a force commit to disk to flush a write buffer 

of the storage device and ensure that the overwrite 

array is actually written to the storage device; 
closing the handle to the file; 20 
passing the delete call down the file system such that 

proper flags are set for the delete call to have properly 

completed; 
overwriting a filename of the file; and 
modifying the delete call into a get file attribute call and 25 

passing the get file attribute call down the file system 

layers. 

12. The method of claim 11, further comprising: 

prior to the step of closing, checking whether additional 30 
overwrites should be performed; and 

if so, repeating the steps of overwriting and generating, 
each overwrite iteration using a different overwrite 
array to attain increasing levels of security. 

13. The method of claim 11, wherein the step of over- 35 
writing the filename of the file comprises: 

reading sector zero, which is the boot parameter block, of 
a logical drive containing the file to obtain information 
about a geometry of the logical drive; 

determining a file allocation table (FAT) structure of the 40 
logical drive; 

reading a cluster that contains the directory structure 
containing the filename to be overwritten; 

parsing the directory structure within the cluster to pro- 
cess each field within the directory structure, wherein: 45 
if an active filename is encountered, rebuilding the 

directory structure with the active filename; and 
if a deleted filename is encountered, overwriting the 
deleted filename with a specified overwrite array; 

checking whether the sector or filename that initiated the 
overwrite has been reached, and if so, advancing to the 
step of forcing; 

checking whether the entire directory structure has been 
parsed, and if not, returning to the step of parsing; ss 

forcing an absolute disk write of the rebuilt cluster 
containing the active filenames. 

14. The method of claim 13, further comprising repeating 
the step of overwriting the deleted filename for a specified 
number of iterations, each overwrite iteration using a dif- 60 
ferent overwrite array to attain increasing levels of security. 

15. The method of claim 10, wherein if the intercepted file 
system call is a write call, the supplemental processing 
comprises: 

intercepting the write call only if the write has a length of 65 
zero which indicates that the write call is placing a new 
end-of-file (EOF) marker, 
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determining a position for the new end-of-file (EOF) 
marker directly from the write call; 

obtaining a true file size of the file using an enumerate 
handle function; 

determining overhang, if any, of the file based upon the 
true file size and the position of the new end-of-file 
(EOF) marker, where the overhang is a portion of the 
file that existed prior to the write call and that extends 
past the new end-of-file (EOF) marker; 

overwriting the overhang with a specified overwrite array 
by directing the intercepted write call to the file system 
with changed parameters such that the overhang is 
overwritten and committed to disk; and 

passing the intercepted write call down the file system to 
place the new end-of-file (EOF) marker as originally 
intended. 

16. The method of claim 15, further comprising: 

prior to the step of passing, determining whether addi- 
tional overwrites should be performed; and 

if so, repeating the step of overwriting, each overwrite 
iteration using a different overwrite array to attain 
increasing levels of security. 

17. The method of claim 10, wherein if the intercepted file 
system call is an open (create always) call, the supplemental 
processing comprises: 

directing a "ring zero" open call through the file system; 
when the ring zero open call is passed back, determining 

whether a handle for the file is returned; 
if a handle is returned indicating an existing file, directing 

a ring zero delete call for the existing file which it than 

processed as with other intercepted delete calls; and 
if a handle is not returned, passing the intercepted open 

(create always) call down the file system. 

18. The method of claim 10, wherein if the intercepted file 
system call is a rename call, the supplemental processing 
comprises: 

opening a handle to the file; 

closing the handle to the file; 

overwriting a filename of the file; and 

passing the intercepted rename call down the file system. 

19. An apparatus for enhancing file system calls to a file 
system structure of an operating system, comprising: 

a storage device; 
a memory; and 

a processor, the processor executing an operating system 
that provides a file system for managing data on the 
storage device, 
and the processor executing a driver within the file system 
such that the apparatus operates: 
to intercept a file system call, the file system call 

intended to perform a function with respect to data 

stored on the storage device; 
to determine whether the file system call is of a type 

that should be processed; 
if the file system call should not be processed, to pass 

the file system call on through the file system; and 
if the file system call should be processed, to perform 

supplemental processing to enhance the file system 

call and transparently returning the file system call to 

a calling system application; 
wherein the supplemental processing enhances the file 

system call to provide real-time secure file deletion 

on the storage device, and with said real-time secure 

file deletion occurring at substantially the same time 
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as said file system call performs said function with 
respect to data stored on said storage device. 

20. The apparatus of claim 19, wherein the operating 
system is WINDOWS 95, the file system is the installable 
file system (IFS) of WINDOWS 95, and the driver is a 5 
vendor supplied driver (VSD) executing within the install- 
able file system (IFS). 

21 . The apparatus of claim 20, wherein the file system call 
is from the group consisting of a delete call, a write call, an 
open (create always) call and a rename call. 10 

22. The apparatus of claim 21, wherein the supplemental 
processing is based upon the type of file system call inter- 
cepted. 

23. A storage device comprising: 

stored data representing object code for a driver for 15 
enhancing file system calls to a file system structure of 
an operating system; 
the driver, when executed, operating: 

to intercept a file system call, the file system call 

intended to perform a function with respect to data 20 

stored on the storage device; 
to determine whether the file system call is of a type 

that should be processed; 
if the file system call is of a type that should be 

processed; 25 
if the file system call should not be processed, to pass 

the file system call on through the file system; and 
if the file system call should be processed, to perform 

supplemental processing to enhance the file system 


call and transparently returning the file system call to 
a calling system application; 
wherein the supplemental processing enhances the file 
system call to provide real-time secure file deletion on 
the storage device, and with said real-time secure file 
deletion occurring at substantially the same time as said 
file system call performs said function with respect to 
data stored on said storage device; and 
wherein the driver, when executed, further operating: 
to monitor the file system to determine whether addi- 
tional data overwriting is required for complete data 
deletion, including the deletion of any trace of said 
data remaining during or after the deletion process. 

24. The storage device of claim 23, wherein the operating 
system is WINDOWS 95, the file system is the installable 
file system (IFS) of WINDOWS 95, and the driver is a 
vendor supplied driver (VSD) executing within the install- 
able file system (IFS). 

25. The storage device of claim 24, wherein the supple- 
mental processing enhances the file system call to provide 
real-time secure file deletion on the storage device. 

26. The storage device of claim 25, wherein the file 
system call is from the group consisting of a delete call, a 
write call, an open (create always) call and a rename call. 

27. The storage device of claim 26, wherein the supple- 
mental processing is based upon the type of file system call 
intercepted. 
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